If you haven’t read The Pragmatic Programmer (PP), you probably should. It’s the best software development book I know.
Liking the original book so much I have read most of the other titles in Pragmatic Bookshelf. Here’s what I think of them.
General software development books
The original and the best.
Paraphrasing the book’s philosophy in eight sentences: Do you want to be a great programmer? Do you want to be treated with respect? Do you want to influence the decisions made at your company? Then take the individual responsibility. Think about what you do and how you do it. Invest time in finding about alternative solutions. Hone your skills. And above all: be proud of what you do.
The book offers practical, concrete advice on self-development, software design and everyday software development skills. There’s a summary of the book’s tips available at the publisher’s website.
This elaborates PP’s ideas on agile practices and team issues. It’s not bad and if you want to know about agile, I would recommend it as a possible introduction to the topic. However, unlike PP, it didn’t really offer me any fundamental new insights into programming. I feel it’s quite redundant to PP and to Ship it!
Ship it! is similar to Practices of Agile Developer in that it elaborates PP ideas towards team collaboration. In fact it is so similar that when I looked at the table of contents before writing this sentence, I realized I had mixed parts of the two books in my mind.
Of the two, I feel Ship it! offers better, more concrete advice. Among them: Script builds on day one, Work to The List, Always review all code, etc. This is dogmatic, although lightweight stuff. You don’t have to agree with all of that to enjoy it.
The practice the book devotes most pages to is tracer bullet development. The idea is to create a working end-to-end system first. (E.g. from user-interface of the client to the database behind the server.) This early system doesn’t have to have any actual functionality. After the system works from end-to-end, we start implementing the functionality, filling in the details to the hollow frame. I think it is a good design practice, especially in projects where the overall architecture carries the greatest risk.
My recommendation is to read this book if you enjoyed the style of PP and like to have concrete, team-oriented advice.
This is a book you can finish in one evening. It’s hands-on advice to software management. I don’t have any experience on that, but after reading this, I felt “Hey, I can do this.”
The ideas resonated very well with me as a developer. The goal of management is to empower the developers. This is where this book syncs with the philosophy of the PP. Managers give the tools, but in the end the productivity depends on individual developers.
I highly recommend Behind Closed Doors.
If your company could hire 5 engineers in India with the amount of money they pay you, why shouldn’t they? How can you stay relevant?
The answer this book gives is to realize that the people in India are in a different skill market than you are. There are many development tasks that are more efficiently done in India, but also many that are not. Look at yourself as a product competing in a marketplace: How do you differentiate yourself from other products? How can you make yourself more appealing? How do you market yourself?
The book’s value is in that it is based on real experience. Chad Fowler set up a software development centre for a multinational company in Bangalore. (It doesn’t say so in the book but I think I heard it was GE.) In the process he interviewed hundreds of Indian developers. In a way his career is also a testament of his methods’ worth. After studying music in university, he started programming in the mid-nineties, having no experience on the field before that. He quickly rose the corporate ladder, and now he is in his third career as a Rails expert. (Incidentally, on the back of PP, also Andy Hunt claims to be a musician first, programmer second.)
My Job Went to India is a good read offering a lot of great advice for self-development.
(Also, in Google Video there’s a two-hour talk by Chad Fowler called Don’t Follow the Lemmings that covers a lot of the ideas from the book.)
The Pragmatic Starter Kit
These three books are a series about fundamental techniques in software development, namely version control, unit testing and project automation. I recommend them if you are new to these subjects (as I largely was when I read them).
This is a practical guide to version management best practices using Subversion. It’s good guide if you are new to Subversion or if you are starting a new project and want to remind yourself of the decisions you need to make about organizing your version control.
I’ve also read the sister book Pragmatic Version Control Using CVS that is written by Andy Hunt and Dave Thomas. Although the book has different authors, most of the text is identical.
This book describes what unit tests are, why we need them and how to write them well. It’s agnostic about tests-first vs. tests-last debate.
The book is good but not great. I would have liked to know more about how to name and organize tests in an efficient manner. Also, some better guidelines about how many tests to write would have been good. Finally, the book is three years old, and unit testing best practices have continued to evolve in a fast pace. Among other things, behavior-driven development has certainly clarified my view on unit testing.
That said, I don’t know of any better unit testing books than this.
There’s also a sister book Pragmatic Unit Testing in C# with Nunit.
This book introduces the means to automate your builds, unit tests, releases and logging. The book is Java-centric and concentrates on Ant, CruiseControl and log4j. I haven’t done much Java programming after I read this book so I haven’t got a lot of benefit out of reading it yet.
Often referred to as PickAxe, this is the definite Ruby programming manual. The first edition is freely available on the web. The book has two parts: the first half of the book is tutorial and the rest is a reference manual.
I have used this as my primary Ruby reference since I started and have been pretty happy with it. It covers the core language and the built-in classes very well, but not the standard library. When it doesn’t have an answer, my secondary sources are Google search, and finally looking at the Ruby source code if everything else fails.
Nowadays, there are many other Ruby books. I haven’t looked at the other programming manuals, but it seems like people still find the PickAxe the best one.
This is a very good introduction to Rails that can also be used as a reference. I recommend this book to Rails programmers and everyone interested in learning Rails.
This is your standard recipe style programming book. If you are a Rails developer, you should look at the table of contents and see if there’s anything worthwhile to add to your tool belt. Personally, I haven’t used the recipes as much as I thought I would.
The book covers Ruby libraries to handle common ad-hoc integration tasks such as parsing XML, connecting to database and remoting with SOAP and REST. I have found this book surprisingly useful, using it as a reference manual to those tasks.
The book defines Enterprise Integration as something that happens whenever an existing enterprise resource is used to achieve some result. Enterprise systems are often very hairy, and thus there is a great need for simple integration tools such as Ruby. I have never worked in a large company so I have no idea how well these techniques work in an “enterprise” environment.
TextMate is a text editor for Mac. It’s like Emacs brought into the 21st century. Like Emacs, it is very extensible, and has a keyboard shortcut for everything. Unlike Emacs, mere mortals can use it without a two-week crash course. In fact, TextMate is quite usable and Mac-like.
So, why do you need a book about it? Well, you really don’t. With the TextMate help and the screencasts you learn pretty much everything you want to know about TextMate. That said, I found the book very readable, and learned a lot that I didn’t know about the editor.
Inspired by the book I actually wrote my first TextMate extension before writing this blog post. Now whenever I type a book’s name and press CTRL-SHIFT-APPLE-A, TextMate fetches me a link and an image tag to the book in Amazon. It took me about 45 minutes to write, most of which I spent looking into the Amazon API. I think I have already saved that time by not having to link to all these books manually in this post.
The funny thing is, I didn’t need to look at the book at all when I wrote the extension. It’s that simple.
This was one of the first Ajax books. It explains what Ajax is and has a lot of code examples in Java and Ruby. I haven’t read any other Ajax books so I don’t know how it stacks up against them. The book feels quite shallow in each of its subjects. I imagine that if you want to learn Ajax on a specific platform, an Ajax book targeted to that platform will be better.
In this book, data crunching refers to solving everyday tasks with short scripts. The main topics covered are text manipulation, regular expressions, XML manipulation, handling binary data and SQL queries. If you happen to be in a situation where you don’t know most of these things already, then go ahead and read this book. Otherwise, I don’t think it’s worth it. The main lesson to draw from the book is that there are plenty of opportunities to use your scripting skills in everyday tasks.
Books I haven’t read yet
I just realized it’s been a while since I last looked at the complete Pragmatic Bookshelf. Now that I did I think I will order these soon: