Wednesday, March 24, 2010
Saturday, March 20, 2010
This blog post "Human-tool intellectual partnership" made me think on our own field. Here's some thoughts of mine.
As long as I've been around, I've heard people bring up the phrase "a poor craftsman blames his tools." With the rise in the software craftsmanship movement and the associated (oft-misrepresented/misunderstood/misapplied) terminology, this happens even more often.
When someone talks about how you are more productive with Rails than with some other frameworks, out comes the 'a poor craftsman blames his tools.'
When you talk about how using a dynamic language offers affordances and design possibilities that a static language, such as C# or Java, doesn't you can hear the cries of 'a poor craftsman blames his tools.'
How often would you see a professional, custom-furniture maker use a saw to pound in a nail, or use an awl to attach a screw. Could they pound in a nail with a saw? Sure, I bet they could. But they don't. They choose the right tool for the job. And therein lies the rub, I think: 'the right tool for the job.' Everyone has their favorite tool, but, for everyday work, I'm sure the furniture maker tries to keep their general toolset up-to-date, replacing older, less-effective versions of a tool with more productive ones. Having a manual screw-driver is great and very important for certain situations, but having an electric one can help tremendously when trying to be productive. A professional tends to have a whole slew of tools, used effectively at the right time.
Why do we, as programmers, have a tendency to defend our possibly old, less-effective tools. Personally, in the past, I've fallen into the trap where I made judgements about a new tool before giving it a real shot, assuming I understand it before I've given myself a chance to become familiar with at least the rudimentary subtleties. Perhaps I held to the belief that 'all tools are equal, it is just a matter of how you use them.' Over time, with experience in different realms, it becomes abundantly clear that this is patently false. Can you do most anything with any tool? Sure. Should you? No.
Does this mean that there is only ever one 'best tool for the job?' No, I'm not saying that. But, there are certainly a whole slew of tools/languages that are average-at-best with their appropriateness. Here's a statement: the more 'general-purpose' a language is, the worse it is for the majority of the tasks we use it for. This is why you see an significant increase in productivity in languages built on top of Ruby, such as Rails. They are fine-tuned to be effective and productive in a constrained set of tasks. This is why you often see people writing the solution to a problem in the language they wish they had, then implementing it in their underlying, general-purpose language.
Snarky comment: ever notice how, in general, the people who like to chime in with 'a poor craftsman blames his tools' tend to be the ones who use crappy tools. :)
As always, thoughtful comments are appreciated. Blog posts are even better.
Tuesday, March 16, 2010
If you'd like to get in touch with J.B., you can contact him through his website.
Enjoy! And, as always, comments are welcome, but blog post responses are welcome even more!
JB Rainsberger - Value Objects from Corey Haines on Vimeo.
Tuesday, March 9, 2010
Gary did an incredible refactoring screecast, as well as his much-talked-about presentation at Northwest Python Day, called Python vs Ruby: A Battle to the Death.
Gary organized the Seattle stop on my coderetreat tour 2010, and I made sure to get a chance to sit down and record a conversation with him. In this video, we meander a little bit, but focus primarily on some of the differences between the ruby and python communities, especially as it relates to testing habits and ideas.
Enjoy! And please leave comments if you are so inclined. Blog post reactions on your own blog are also highly encouraged.
Tuesday, March 2, 2010
While in Romania, facilitating the Bucharest Coderetreat, I had the opportunity to teach a Test-Driven Development class with J.B. Rainsberger. We've talked about teaching together for many years, and I'm honored to have finally had the opportunity. If you have watched the videos that I did last summer with J.B., you'll know that he has an amazing amount of experience and insight into the development process. He has an ongoing blog called 'The Code Whisperer,' which has consistently thought-provoking content on design, testing and other coding techniques. If you haven't watched them, I urge you to look through the archives for them, as his thoughts on test-driven development are enlightening.
Whenever I have time with J.B., I do my best to get some videos recorded with him covering whatever might be of interest to us at the time. This past opportunity was a goldmine, as, not only did I get 3 videos, but we also used ustream to live-stream the interviews. While I was copying onto my computer, J.B. was kind enough to do impromptu Q&A sessions with the people viewing.
This is the first of those video interviews, focusing on the often-mentioned, more-often-misunderstood topic of 'Primitive Obsession' in design.
Enjoy! As always, constructive feedback is welcomed in the comments. If you are so inclined, please write a blog post with your thoughts.
Coming next week: Gary Bernhardt discusses some of the differences between the ruby and python cultures.