There are many roles beyond just "coder" that are essential to developing technology solutions.
It will of course depend on your organization which of those roles you need to take on.
I like this diagram from the IBM article Elements of Service-Oriented Analysis and Design
As you can see, there are nine different roles or boxes that you need to fill: from Business Analysis in the upper left, all the way down to yes, Application Development (coder) in the bottom right.
As librarians are expert in their business area, it seems to me that the Business slice is a key role. As well, Architecture, which bridges between business needs and application tasks, is another slice that needs to be considered. Now I understand in a small organization you may need to play many of these roles, but it's important to know what hat you're wearing at any given time.
Additionally, in organizations where there is IT support, it may be that the reason the desired solutions are not being created is a communications gap, not a coding gap. You may need to speak in Business and Architecture terms, or to translate Architecture into Applications Analysis, in order to get the IT group to understand what you want built.
I just think "coder" represents such a small component of successfully delivering systems that meet your goals - think in wider terms about how to
- Capture your goals (Business)
- Translate those goals into sets of functions that make sense for the organization (Architecture)
- Build systems that meet the business goals while fitting into your architecture (Applications)
So yes, of course, Access Hackfest (2005, previous years) and code4lib conference help to move libraries to better (and cooler) systems, but there are many other angles for approaching system improvement. You can work on Enterprise Architectures and Service-Oriented Architectures that provide amazing new capabilities, without ever writing a line of code yourself, as long as you can find resources (CS students? consultants? your IT staff? even--dare one imagine--vendors?) that can take those architectures and turn them into running code. If your goals and architecture are clear enough, the coders don't need to be library experts in order to deliver the functions you need.
And I want to emphasize the importance of correctly identifying your goals before your requirements. If your goal is better user engagement, well, I can't put it any better than Roy Tennant
I wish I had known that the solution for needing to teach our users how to search our catalog was to create a system that didn't need to be taught—and that we would spend years asking vendors for systems that solved our problems but did little to serve our users.
Also, don't try to build big complex systems. Live in the beta world. Get some chunk of functionality out quickly so that people can play with it. The hardest part is having the initial idea, and the good news is I see lots of great ideas out in the library blogosphere. I can understand the frustrations in the gap between the idea and running code, but I hope I've presented a bunch of areas above in which you can work to turn the idea into the next hot beta, without necessarily needing to code it yourself.
The systems world is not just buy/build. It's buy, build, transform, collaborate, extend, transform, inspire, lead...
Many of these themes have come to mind as I prep my presentation for Friday's SOA Symposium.
September 26, 2005 librarian.net : Dan Chudnov “more librarians need to be coders”
October 01, 2005 LibrarianInBlack: Library Code Monkeys Wanted
October 07, 2005 Library Web Chic » Librarians as Coders
November 07, 2005 librarian.net : 15nov Buy, Hack, or Build: Optimizing your Systems for Your Users and Your Sanity
November 21, 2005 LibrarianInBlack: Talking to IT
November 23, 2005 The Shifted Librarian: How Badly Do I Want a Programmer at Work?
November 23, 2005 Information Wants To Be Free » Coders wanted. (an exceptionally insightful summary)
December 01, 2005 Information Wants To Be Free » Web/Library 2.0 Backlash
December 05, 2005 Tame The Web: Libraries and Technology: Library 2.0 is not about Technology