I am quite interested in a wide swath of technologies, some esoteric, some popular. Particularly, I follow the news on various libraries and tools. I like to keep my toolbox full.
Although I'm usually quite busy and I currently work in Java, I keep my finger on the pulse of other systems. I play around with Ruby, with PLT Scheme, with Perl. I look around for Emacs hacks. I read various planets and aggregators. I check out what people are working on. Mostly, I look at what I can put in my toolbox.
I try to learn what other people are using, what libraries they're using, what tools and IDEs they're working with. I don't do this out of envy— I know my tools are still inadequate, and my toolbox is still bare.
Take, for instance, Microsoft's LINQ. LINQ is essentially a language-level query system in the .NET universe, particularly in the Orcas release of Visual Studio.NET and the .NET runtime. It allows you to write queries as part of your source code, complete with syntax checking and with the support of your language's data structures, etc. Of course, I'm glossing over some of it's really nifty bits, but you get the point.
Someone asked the PinoyJUG mailing list about LINQ and Silverlight and what Java has to offer. It got me thinking about the tools of my trade, and the tools in my toolbox.
Are my tools sufficient for the job at hand? Are the stuff we have in the Java space sufficient for what I do?
I disagree.
The tools are never "sufficient"; they're usable for the job at hand, they do the job, but they have their quirks and issues. For example, if Spring or any dependency-injection framework wasn't in your repertoire, you'd think that the Factory and Service Locator patterns were sufficient, were enough, to do the job -- and you'd be blinded by the problems of those patterns, that those patterns are not the end-all-be-all. However, Spring isn't a silver bullet— dependency-injection has it's own quirks, it's own series of questions. How do you refer to "soft" dependencies? Why do I have to write tons of XML? Setter or Constructor injection? What about bean lifecycles? Cyclic dependencies? Hooking it up to legacy systems?
If you ask me, it's not about looking for the tool when you need it, but rather what tools you already know will help you deal with the problem, or will help make the problem amenable to your other tools. So goes the aphorism "If the only thing you have is a hammer, everything looks like nails": by expanding our knowledge of what tools are available, creating new tools, and fixing existing ones we get to write better code.
Tools transcend code and libraries. When I refer to tools I also refer to how to think of the problem. One can borrow the paradigms of functional programming to write Java inner classes and nested classes to parameterize or box behavior, for example. One can grok C++ templates and their patterns of use, and use it to metaprogram in Java.
My point here is that as someone in the business of writing software systems, I do not sit still and just passively look up resources as I need them. I become a better coder by reaching out and enriching my toolset, and by that I can write better software.
But in the end, only one truth can be said about tools:
There is no silver bullet.
Previously: Work, Browsers, and Context-Switching