View source for 2013 breakout lone technologists

==Lone technologists at small libraries==
===Wednesday Afternoon Breakout Session, Room E===
*Discussion Leader: Ken Irwin, Wittenberg University
*Notetaker: Amy Deschenes, Simmons College

Main sessions related to things you can accomplish with teams of people. What are lone technologists or very small teams doing? 

Common theme of the larger organizations putting restrictions on libraries/archives. Some content management systems are imposed. Systems do what they need it to do, but can't customize it as much as we'd like.

It's difficult to find time to evaluate available platforms, tinker with it and roll it out to users.

How do you evaluate what is a worthwhile use of time in terms of customization of out of the box systems?

We don't always have budgets for buying products, but can use human resources to build stuff or customize open source products. On the flipside, sometimes systems are purchased and then you can't customize them.

Maybe small institutions would be helped by stronger project management practices. Use an administrator as your "block" - people have to go through your manager or this administrator rather than directly to you.

Keep a running list of projects we'd love to have and show how much effort these would actually take. 

You could try community support or consortial support, especially for infrastructure support.

Some people are applying for grants, but for smaller teams, it's only worthwhile to take the time to apply for grants when it's almost a certainty you will get them. LSTA grants don't get as many requests from academic libraries, so this might be a funding possibility. Others say LSTA grants are good for when they're for the larger community (academic and public/government installations).

Tie in with the larger institutional goals; demonstrate what works for you and why you need the special functionality/server space/etc.

Cultivating a buddy in IT and work on relationship building. Get a virtual machine or WAMP/MAMP server and build it locally, then show and tell with IT department.

How do you know if you're doing customization or implementing open source well? Where do you go to get feedback? Could push out code to github and ask larger community for feedback. The rest of the world isn't at all like your own server environment. 

One good habit: go back and look at something after 3-4 months have passed with fresh eyes. 

Document your own processes or reasons why on a wiki, so you can hand it off or review at a later date. Follow documentation standards whenever possible. Make readme.txt files so your future self or another person will have a clue what you were thinking. Write the block comments before you write out the code. 

Take the extra time at the beginning during planning rather than spending more time on cleanup later on.

Challenges with git for loners - kind of like talking to yourself. Am I doing it the right way or just the way that's working for me? Major question: different environments all on the same repo or keep them separate? Documentation seems focused on beginners or mega experts - need steps 2, 3, 4.

Put environment configuration into the program itself instead of the Git space. 

What can Code4Lib do for lone technologists or smaller teams?
- Examples of good smaller projects that are achievable for single person.
- Develop stronger collaboration spaces for lone technologists. Mini-community project. Someone needs to take ownership of it.
- If you want access to Code4Lib github, just ask. 
- Expand the list of stuff for beginners. It's bewildering!
- Knowing how to pick the right tools.

What are Code4Libbers working on?
- ILS
- Digital Libraries
- Library website
- Institutional Repositories