The Page

From a 1974 "Classic Peanuts" cartoon, Peppermint Patty has been recruited to toss the football to Good Ole Charlie Brown. She does with a vengeance, and three panels later the result is a resounding "BONK" on the head as Charlie Brown misses the football. "Coordination and Communication... Those are your problems, Chuck!", Peppermint Patty says. "Your mind tells your body to do something, but your body doesn't obey... Your mind and your body have to work together..." Charlie Brown replies, "My mind and my body hate each other!"

Talking Turkey to a Techhie shouldn't have to be an exercise in mind and body hating each other, as a matter of fact, we hope it is exactly the opposite! That being said, communication and working alongside technical support persons in a library often has its "BONK" moments.

We look today at three fundamental areas of talking turkey to a techhie: Universal Truths, Communication, and Coordination.

Universal Truths

Universal truths are those "givens" which hopefully lay the foundation for good communication and coordination. Sometimes the Truth hurts. Sometimes the view of the truth is looking through the glass half-empty rather than half-full. Generally, though, a good reminder of what basic truths drive us goes a long way to establishing the ground rules.

Alligators are defined as those who "legitimatize" any given project or idea. Alligators can be good or bad. Who on your staff makes a project succeed? Who on your staff can mothball the most innovative idea since sliced pie? These are your alligators. Know who they are and communicate accordingly with them. They can be extremely helpful individuals in opening doors and keeping them open in a given project if you have their support; they can be extremely damanging to your project and your career if they throw obstacles up in your face every day to sap your energy. Know who the alligators on your staff are.

Similarly, know who your heroes are. There's a great deal of truth to the old adage, "He who has the most passwords that work, wins." We have all been in a situation where the passwords don't work, where the system doesn't boot, where life, particularly email, does not function as we know it. Know who can fix it. Be kind to them. We all know library automation isn't as critical as hospital automation, but when the systems *are* working, take time to thank them.

It is a reciprocal given that praise and rewards go a lot farther than criticism and cynicism, but it must be precisely that: reciprocal.

It goes without saying that libraries are about public service. It goes without saying that technology is always at the forefront and cutting edge of new and exciting things. The problem comes when technology forgets its mandate to be mindful of public service attitudes, and librarians sink back into that comfort zone that's far removed from cutting edge behavior. Both have their pitfalls. The easier way out is not necessarily the most rewarding. To achieve success, both parties need to be mindful of the best of public service attitudes and issues as well as preparing energetically for cutting edge technologies and strategies. The secret is not to consider each thought separately, but to combine the two for a winning combination strategy.

The value we place on time, and the value we place on busy individuals, is another mutual undertaking. No one wants to feel like their time is wasted, and everyone knows that time is important. We respect one another greatly when we honor each other with the space and time and value each party deserves.

At the end of a project, one must try to separate the chaff from the wheat and evaluate how the process and the project went. Shrieks of "I'll never volunteer for that again" or "I want nothing to do with that person" are *not* the optimal result most of us are looking for in collaborative efforts. That being said, most projects do need to be evaluated for not only failures, but successes. To *not* evaluate projects, even retrospectively, does a disservice to those who are involved. Even better is to evaluate at various milestones, to keep focus and on track (which we'll mention later). Providing feedback on how we did our jobs, and what remains undone or tabled for a new phase, is critical to coming to closure and summarizing for both the directly-involved persons as well as peripheral staff who have been gazing on the sidelines. Strive always for completion : evaluate completely.

All of us value quiet time. Many of you may think systems people *never* have quiet time. We do, but often we squander it. Sometimes if we're lucky, quiet time might give us about "3"0 minutes in the morning before everyone else gets in to work, which allows us time to read our email. More often than not, we have have to work hard to find quiet time. And when we do, even if it's a half hour before closing time on a brain-dead Friday afternoon, we often let it slip through our fingers.

The secret to success, and to delay burnout, is finding and using quiet time effectively. This, too, is a partnership. It is given, and it is taken. An old boss from one of my former lives, always said he had an open-door policy to listen to problems. Problem was, he was never in the office, so the door was always shut while he was "out of town". When he was in town, the door was open, but there were always half a dozen people holding up the doorframe telling jokes about football games with coffee cups in their hands, so if you had something important or confidential to say, you had to sort of run scrimmage through the human door props in order to get to the open door. Needless to say, he didn't last long in the position.

Saying you're "available" or that you should have quiet time is only part of it. When you're actually given it, use it. Don't squander it.

Downtime is something we don't like to think about. But, like war and taxes, it happens. Downtime can be less painful if we accept it will happen and work positively to make it as short and well-planned period of time as possible. If a system has to be up 24 hours a day, inevitably downtime will take a chunk out of it. If at least portions of the week can be agreed upon to be *gray* times (scheduled to be up, but if down, don't panic and no need to page), this helps give systems staff some flexibility.

Beyond the gray areas, planned and scheduled *day* downtime will happen. Outside vendors are not as amenable as your staff, often, to coming in and working after 6 p.m. on Saturdays. (If they are, check your budget, they're probably billing you time and a half for it!)

That being said, systems staff also do like to sleep in, get home in time for supper, and have weekends to themselves. Coordination and communication with branches for bad and good days, particularly for *planned* upgrades is very much desirable, when possible, by systems staff if they want to stay friends with the remote users. If downtime has to be coordinated among one or more departments, outside software vendors, or heaven forbid, telecom contractors, well, think of all the positives in the world to make that downtime fruitful and satisfying.

You can chain paperclips together, gossip, or you can clean your desk off. Use the time period to train students on disaster or down-time procedures. If given enough advance notice by systems whole vacations can be arranged for, or at least field trips for breakfast, or a donut run, or something!. LIVE for these times! Ask your systems people for MORE OF THEM!

Ethics and confidentiality are issues that librarians hold high and dear. Surprisingly, even among hackers, honor is prized. Systems staff should be well versed in confidentiality of data, hacking policies, and legal use of software and data. This is particularly true if a lot of student workers are co-mingling with your systems folks. That being said, library staff, including pages, janitors, and patrons, need to take care to not overstep legal and ethical guidelines on copying of software, access to student data, sharing of passwords, etc. Again, the goal, the intent is the same. Both librarians and techhies must act responsibly and can act responsibly without placing either party in a compromising situation.

Communication

Communication is, for techhie and librarian, the key component of survival, as it is for many professionals. Communication is more than just defining acronyms and spewing out geek-talk. It is listening, praising, evaluating, and exercising the highest forms of courtesy.

One of the most discouraging things I am often told is "this happens all the time and no one does anything about it", when in fact it is the first time I've heard *anything* about it. Likewise, when a project or a task is completed, I'm not interested in seeking pats on the back, but I'd sure love to know if the person I've completed the project for is a) using it; b) satisfied with it; and c) has any changes or additions to it. Instead, there's often a black hole. It's not good feedback.

Systems people sometimes feel like they can't do anything without documenting it. You can't just log on to Amazon and order software. (Well, you can, but no one on campus will pay for it!). You have to get a DPR, you have to have several people sign it, you have to remember to forward the invoices when you get them, you have to remember to record it on the inventory spreadsheet, and on and on and on. Several months ago, someone suggested that we obtain helpdesk software so we could keep track of things. I laughed and said, that's good, we'd spend all this time inputting things into another system and no time on getting them done! Of course, helpdesk software is tremendously helpful, but only if you are already *documenting* what it is you are supposed to be doing!

It's the little things that getcha. Lost phone numbers. URLS. Serial numbers. Who said what to whom first, and after the fact. What was the quote last week versus what was the quote this week? Is it on state contract or not? Document, document, document.

Documentation for the sake of looking busy is not what I'm talking about here. Documentation of your work duties every 15 minutes is a sure sign that something is not working with the position or the person, and is a sure way of obtaining evidence either that the person can't handle the job, or the job is too big for the person. While job/time analyses have their place, what I refer to here the ability to survive. We pass way too much information through our brains to remember everything. Write it down. Don't lose it. Have it available for instant "withdrawl" when someone asks for it. Systems people are the databank for systems stuff, much as catalogers are the databank for the subject cross references of the world. From the library and user community, systems people would very much like to see and hear about the problem *before* it becomes a frustration, and, if, just, by any chance, we actually are able to solve it successfully, a kind word of acknowledgement to let us know you're happy with it would be very much appreciated. Both parties can document *more* to the benefit of both.

That being said, if we actually *do* succeed and do something right, there's definitely no excuse to turn down *any* chocolate of any sort in the systems community. And if you really, really, like what we've done, feed us. We promise to give you instant positive feedback if you do!

Continuing beyond simply documenting the quality of our discontent, it would be helpful in some staff cases (alligator or no), if an atmosphere is created in which questions are welcomed, yea verily, even encouraged, and if librarians would and could speak up when things go bump in the night. That being said, when a techhie receives notification of a problem, and particularly if the item is something that isn't a 10-second solution, it would be helpful if the techhie would acknowledge that the problem is under consideration. This may seem trivial, but many of the problems that get logged with systems people are not solveable in 10-seconds or less (what we call the "DUH!" logs, things we know immediately what needs to be done and can be done quickly).

It is helpful if systems people can take the time, to let the person *with* the problem know that systems is working on it. Problem acknowledged, now I'll get back with you in about an (hour)(day)(week). There is nothing wrong with taking *think* time with projects, the problem more often is that the person may have expectations that you're sitting on the project, or worse, still don't know it's a problem. The resulting lack of communication is frustrating and often itself becomes yet another problem.

We should also pause briefly for a moment and consider the squeaky wheel analogy. Sometimes alligators are the squeaky wheel, sometimes they're not. More than often squeaky wheels get the grease, i.e., they get the attention first, or fastest. That has its place, and one of the roles librarians need to learn is when to squeak and when not to. The flip side of that role, is, more often than not, if you shrug your shoulders, act nice and passively and say, "oh, well, sometime, you know, if you have a chance, I'm not in any hurry", you're sort of opening yourself up to being run over by the squeaky wheel on the organizational chart. Systems people are not immune to being influenced by squeaky wheels *or* passive requestors. Passive requestors are a godsend on some days, but that doesn't mean they are to be ignored. Both techhies and librarians need to understand when to be squeaky and when to be passive, and how to be fair to both.

It may seem obvious, but feedback is important. Not just praise, not just criticism, but feedback. If a project is partially designed or completed, when a techhie asks you to test something, *jump* at the chance. It's extremely helpful. Techhies often like to do things all on their own, then can be "hurt" when users change their mind and don't like it. Ask for feedback along the way. It keeps the project on track, and allows for regular contact and communication during the duration of the project. Similarly, give feedback, especially if you have a shy techhie. This doesn't necessarily mean asking for a 5-page themographic essay each day on the progress of the project, but sometimes a simple "how's it going" or "I had another idea" can get a techhie talking. The more interchange the better, without a doubt.

Systems projects aren't like bibliographies. They rarely fit neatly onto 10 pages not counting footnotes, they rarely have a beginning and end, and even more rarely can you ever say with some satisfaction, "there, that's done" about the time you send it to the printer and sigh with relief. (In all honesty, that's about the time the systems problems kick in, when the printer jams...)

Systems people have the same desire to sigh with relief as any one else. Their problems are often more intricate and inter-related to other machines, people, departments. Too often projects seem to stretch on and on, or the software bugs just lead from one to another, and it is a really rare day when the techhies can actually look at one another and even *tell* you what they've gotten *done* in a given day before they go home.

It isn't for lack of trying, believe me. Clearly, even in the largest of projects, such as an integrated library system migration, the project isn't one large project but several embedded projects which comprise the whole. If your systems people are having difficulty completing projects, or often come up with only 80% fixed, partial solutions, perhaps more management is necessary to break down those projects into smaller, more completable tasks, which not only give success to the techhie, but stages of "completion" to the end user. Completion, and closure, are a necessary part of good mental health.

Both of these probably seem like pretty caustic comments. But both comments get at the nub of some difficult communication issues. The librarian needs to have at least one go, maybe even more than one, of describing the issue without being cut off or being told "I know what your problem is". Fine, if you know what the problem is, listen and let them speak and vent, because you know what the solution is and it'll only take a moment. If you don't know what the problem is, you *still* need to listen, it's amazing what you can learn from that one last off-the-hand comment. Listening fully is critical to uncovering clues.

Similarly, however, librarians need to get at the point of the issue. If it's not critical whose car you were driving when you had the thought, or if the color of the hair of the individual who reported the PC is not germaine to the error message that the PC gave, do try to hone in a little on what the issue is for the techhie to diagnose. This probably only comes with experience of working with online technical support vendors, but key elements are needed in a "reference interview", just like key elements in a system problem interview. Knowing what questions to ask and what data to look for are instrumental in solving the problem more rapidly. Calling to say "I got error messages last night while I was working" but not writing down the message proper, well, is difficult to replicate.

Listening and descriptive skills, by the way, are not only the problems of techhies and librarians. They are with us from the inception of time and will be with us to our dying days, even if we spend them pushing brooms instead of reset buttons.

Following listening and descriptive skills, providing good examples is probably the number one key diagnostic tool techhies rely on. You can describe ad nauseum what you *think* is happening, but by golly, if you've got an error message in a box, you're almost home as good as gold, particularly with third-party vendors. Now, *they* may not have the answer, but you have a situation, and hopefully you can replicate it, and if you can replicate it, you can debug it and fix it 95% of the time. Techhies need to hone users in on concrete examples, if they don't willingly provide them. Librarians need to provide them as much as possible for much more rapid results. Second only to examples are the ability to provide specific steps in order for a message or error to occur. These are key methods of alpha and beta testing, but they are lifesavers for techhies and end-users alike if both can develop logical expertise in debugging and reporting problems.

Visiting again the issue of downtime or other periods of life we often refer to as "new product downtime", remember that the library calendar is fraught with people coming in and out wanting things (see public service!) Bringing up a new product, or knocking down an old one, often brings out interesting results if, say, 45 high schoolers from Weir happen to be visiting trying to use the periodicals indices, or your public library has begun their children's summer reading program on that first quiet day after Memorial Day that you thought you'd resize files and no one would notice!

Know who your contacts are. Know when times (and seasons) are bad and worse for end users. Know when your libraries and users close and when your windows of opportunity for experimentation, upgrades, and downtime might be. Likewise, it is always helpful if librarians keep in contact with systems staff for critical days that may go unnoticed, particularly if you don't always hang around the water cooler listening for the latest juice. Like, are the Regents on campus this week? Hmmm, might be a good time *not* to do a software upgrade. Are there back-to-back bibliographic instruction classes in nursing this week? Probably not the best day to fiddle with a new version of CINAHL on the web? We've all been there, and the key to solving many of these issues is communication, communication, and more communication.

Humans always perceive of themselves as the most courteous animals to roam the planet, that is, as long as we get the right-of-way at the four-way-stop. Unfortunately, courtesy can't be assumed. Neither can thinking of every possible contingency plan to the point of paralying a department with what ifs. That being said, however, courtesy goes a long way toward solid and positive communication. It cannot be overemphasized. If a lot of complaints center around phrases such as "you didn't tell me", "I wasn't notified", etc., a good healty infusion of courtesy efforts into the organization would probably do wonders for the overall rapport among employees.

One approach to timely communication is the use of milestones: marking places with a line in the sand to come up for breathers. Milestones are necessary in organizing larger projects into chunks, but are helpful even in smaller projects and tasks in breaking them down into who is doing what and when. There are probably three types of solutions in the techhie's world: those that you have answers for and can fix in the twinkle of an eye; those that are fixable but require some thinking; and those that are doable but require strategic planning and extensive committee work. Most systems people always hope that most of the projects and tasks we undertake lie in the middle category.

Progress reports don't have to be anything that require colored paper, desktop publishing, or embedded spreadsheets. They can be as simple as an email with three lines. What is critical is the notification, the "hey, I'm still working on it" aspect, the "hey, this is how far I've gotten" aspect, the "hey, maybe we'll have this done in a week or so" aspect. I'm a firm believer that many of the communication issues and frustrations between librarians and techhies are the expectations of completion. If up front, a techhie can see and define the project as taking 1-day 1-week or forever, there *is* some reassurance from the librarian that it will be completed within an expected time frame. Of course, stuff happens, and delays inevitably occur. But giving evidence of credible estimates, while maybe an art, is extremely helpful in giving status reports to the end users.

And, if you don't know, and you can't tell when the estimated completion is, say so. Don't fib. Talk to your alligators. A former employee always said, "I've run into a glitch". "Define glitch. Is this a 10-minute glitch, a 1 week glitch, or a hole you've dug yourself in?" Librarians (and end users) are a lot smarter that we often want to give them credit for. They may not know what level of software the glitch is running on, but chances are they can see through a snow job pretty easily.

Don't let project management be sabotaged because the project is either bigger than the person brought in to do it, or because the person brought in to do the project is guilty of poor communication. Expectations, and reality, are everything.

Milestones are a good thing. They are like the insistent pebble in your shoe that lets you know you're still alive and well and thankful to be walking with two healthy legs and two quality shoes that fit.

The advent of voice mail has been a boon to systems people. You can actually be on the phone talking to a vendor trying to get a system up while all the librarians get routed to your voice mail telling you the system is down. We really *are* on the phone a lot. We're not just ordering pizza.

It's fair to remember that while techhies live on the phone, they do occasionally have to get on-site to deliver stuff, set stuff up, and, yes, use the bathroom. Try not to follow them around, either physically, or by playing telephone tag asking if they've been there or have gone. Leave them voice mail, and leave the time-management of how long they're at site x to their supervisors. Remember how much you like it when they come to visit you with a new product or a new feature? Well, sometimes they like to get off the phone and visit remote sites just as much as you like seeing them. Use the voice mail for all those other can't wait issues. It really helps them stay organized and focused, especially if they're off site.

We know that voice mail is critical, especially in emergencies. However, email is often preferable because it does two things for both parties: it provides an audit path.

Larger sites cannot function without helpdesk software, and I don't mean to diminish its effectiveness, but as stated before, if you're not organized enough to document what you're doing, having yet another software program to use to document (or re-document) information isn't going to speed up your efficiency.

Email has the ability to provide you with both a megaphone and a scratch pad at the same time. It makes the quick responses of "I think I can do that by Friday" much more viable. That, coupled with its success in automatic feedback and response to the person sending the item, makes it very desirable.

I don't know about other regents sites, but my voice mails tend to fill up, disappear and go *poof* over a certain period of time I don't appear to have any control over it. Emails give me an automatic date and time stamp and are only deleted if I do dumb things on my own time. So long as I organize my emails properly to find them, they give me an excellent record of what I've done, should be doing, or could be doing. And, the added charm is that my librarian community *also* has a record of everything I've promised, waffled over, and succeeded in doing.

Email is a wonderful thing.

An odd sense of common courtesy was in evidence when I first came to PSU many years ago. It appeared that anyone who was on the phone was fair game to have a senior staff member come and stand in front of them and try to convince them to hang up. I'm not sure if this was a result of budget cuts, or just pure bad personal ettiquette. It certainly did not endear me to the people who engaged in this behavior regularly, and it annoyed me a great deal that the value of another colleague who was paying for a long distance call should so easily be interrupted by someone wanting to know why the stapler was empty, for instance.

Similar behavior at the circulation desk also annoys me. Patrons can be queued up in line out to the door to check out materials, and a phone call takes precendence. It is usually evidence of poor staffing during peak hours, but clearly the phone patron does manage to "butt in line". The phone rings. It gets our attention. It is a valuable tool.

Techhies get the majority of their external answers from the phone: from colleagues, from vendors, from support reps. Time is valuable. Money is too, but often to get to the quick of things, the phone is inevitably more valuable than the cost of the call. Try to give your techhies space and time to work the phones. Phones are lifelines. They provide answers. Answers that librarians need.

Seek answers always. Many technical and systems people are experts at working the phones; if they are not, they will be by the time they retire to the old folks home. This is a skill that many librarians do not have. There is nothing so frustrating for a techhie to lose place in a train of thought simply because someone is standing in front of them waving an envelope, or dancing in front of them, or worse, listening and sighing and pacing around their desks. Communication is not always verbal. Neither is courtesy.

Coordination

Coordination is management, making things synchronize in a calm and orderly fashion. Sometimes it tends to be over-heavy in the paper department, but it is a necessary part of "talking" to peers.

The whole documentation game is again a form of audit path: evidence of work asked for, evidence of work completed. The act of writing down, either in paper or email, does several things, which any English major will tell you also purifies the soul in the process. For the librarian requesting the work or stating the problem, it helps organize the process, outlines the steps taken to get x to occur, or provides exact wording of the error message. For the techhie responding back, the act of creating documentation (whether comments within source code, or user documentation), allows a historical moment in time to be carved in cement. User directions, when written down, sometimes outlive whole systems! But each written direction and document saves time: for end users, for end users to come, and even programmers and techhies to come.

The consequences of *not* documenting, are, well, chaotic. If you must know *how* chaotic, you clearly haven't yet been a victim of poor documention, which, I guess is a blessing!

Prioritization probably comes with age. Or laziness. We usually do the jobs we can do easiest and quickest first. The ones that require thought usually require a cup of coffee or at least a breakfast sandwich to dig in to. The ones that require strategic planning and committee work we put off for a rainy day as much as possible.

Prioritization is a key skill that techhies need to develop in order to survive. The project are not just short-, medium-, and long-term in terms of completion. Add the alligator and squeaky wheel variables, and very quickly the logs and projects become fully dimensional. Particularly with new systems staff or student workers, prioritization is a must, especially if certain alligators need *everything* all the time *at once*. (There's usually at least one of these on every staff!)

The best answer to prioritization for the librarian is to know what defines a critical request and what does not. As previously mentioned, no one is going to die on a ventilator if my RS6000 disks stop spinning. That being said, I know that spouses may have burnt suppers and dogs may be kicked if patrons with blocks can't identify what is overdue, or worse, their blocks prevent them from enrolling on key days and their employers fire them.

Even in today's server farms, some servers are more equal than others. Some branches have the priority in certain times of days. Some modules or functions have priority over others, depending on how many people they affect. On days when the systems and servers are malfunctioning, techhies really don't care if:

a) your printer isn't working when you have networked access to at least three others;

b) your speakers on the PC aren't playing WAV files (unless it's the ADA workstation!)

and c) Amazon.com isn't accepting your personal credit card.

While there are whole web sites dedicated to end-user problems, be aware of what hot buttons your techhies have. Have they told you there are days to enter at your own risk? They're right! :_)

As academic institutions, we all live, more or less, by the academic calendars at our respective sites. Daily scheduling is less problematic for us due to class schedules and shift changes. Parking, leaving for lunch, even walking across campus to swap out a keyboard, is often driven by changes in class times.

Scheduling of projects to coincide with beginning and ending of semesters is also not a foreign concept. What is often difficult, however, is staying on schedule (see milestones). The only thing worse than not having a schedule is having a schedule which is behind schedule. Keep bugging your systems staff. As much as is humanly possible, they can give you fairly good estimates of time and success delivery, and *should* keep you informed as often as possible on the projects they are assigned to.

So much of troubleshooting is akin to identifying diseases in the health services. What is cause, and what is effect? Do you treat the problem, or the reaction to the problem? This is particularly difficult in many software debugging issues, especially those that often end up being "hardware" problems when all you thought you had was bad software.

For librarians, always the inquisitive this-is-how-we-learn my-life-is-in-chaos-if-I-can't-control-it beings that we are, WHY is not a bad word. WHY is only a bad word if techhies don't have the answer to WHY!

Technically, there is almost always an answer to WHY, but your systems people may not have it. Or may not have it when you ask it. But generally, systems people will have an answer (eventually), but it might be the most boring, un-romantic bunch of gobbledeygook that you've ever heard in your life.

Librarians are *not* at fault for asking WHY, but generally get dark frowns for WHEN they ask WHY. Knowing WHEN to ask WHY is the secret. Clearly it isn't on the day when the system isn't up, or the techhie has his/her hat and coat on and is three steps out the door. WHY is not a beeper or pager question, but could be considered in email, which can be saved to a things-to-do-list for rainy days.

Techhies like answering WHY when it sorts out a rational progression of steps. "The hold is not placed because branch x forgot to move the item status to trace" is a really good WHY answer, and getting feedback to branch x to correct the abberation in work flow is clearly beneficial to both librarian and techhie. Knowing WHY the webpac crashes when it's on the same server as Norton Anti-Virus is probably not something anyone wants to discuss over breakfast, unless it's a geek breakfast held at Norton headquarters.

Knowing WHEN to say WHY can probably more easily be visualized when the mood of the techhie changes abruptly, or the eyes glaze over or roll out of their sockets. It is one of the great mysteries of life that rival only cause and effect in the overall scheme of things.

Okay, this one isn't aimed so much at librarians as it is the deans and directors. I'll be honest! And libraries have changed a great deal in the past 10-12 years in handling this, but it bears reminding all of us, both parties, to try to book ahead and *enjoy* those crises as much as possible in order to get through them.

Most of the PCs, servers, and software we use today come with fairly incremental upgrades: software releases, memory upgrades, larger disks, etc. We've learned to *not* use PCs to their ultimate death but *schedule* them into obsolescence, or at least move them around the library and share their quirks as they grow old. Revolving purchases around a "3"- or 4-year plan help to avoid the absolute burnups. Remember the old days when monitors went up in smoke? When it did, the whole machine was out of commission until you ordered another one. Nowadays, with rotation issues, you probably still have a half dozen old monitors you can plug in to keep going for a week or two until the new one gets ordered.

If a system printer needs to move from a mux to a network card connection, order the connection and start working on the problem, preferably while the mux is up, working, and still physically connected. Beats having to stay up all night and figure it out when the mux fries in a thunderstorm and all your cash reports for circulation pile up on a print queue that you're not certain you can rescue for two weeks while you figure it out the new hardware, right?

There will always be disks that go bump in the night, and processor boards that forget who they are. Maintenance contracts cost a lot, but they speed up the down time. Time is valuable. Your staff time is valuable. Thankfully most of our directors have been given director-skills in providing rollover and development monies to avoid the brush fires. If you're lucky to have such a dean or director, shake their hand. Tell them how much you appreciate them. And if the money's there, use it. Much as systems people tell you they work best under pressure, schedule their tasks. The only thing better than working under pressure that they *love* is sleeping in on Saturday mornings... when there aren't any brush fires to put out!.

Somewhere, some time back, librarians got the impression that all techhies are geeks. It's not like librarians have their own image problems to deal with, so it's unclear to me how librarians suddenly got bothered by geeks running their systems. I suspect somewhere in the history of computer science the geeks also got bothered by a bunch of intelligent librarians who seemed to be a heck of a lot more organized about stuff than the techhies. And so, we come back full circle to what the mind and the body think of each other.

Actually, techhies and librarians are a lot alike. These are driven, intelligent people. They may not always be the most social, in ways that the world may understand, but they are social animals. Working together has given both parties many more insights than they bargained for, probably!

I visited a library in Missouri recently, and after touring through many departments and many floors, all of the sudden we came to a white door with about three dozen comic strips taped to it. The director asked, "Do you know where you are?" I said, "well it has to be the systems office, because there's cartoons taped to the door".

Techhies cruise the web, and look busy a lot of time. But they learn a lot of stuff cruising the web, and looking busy isn't a bad thing if the brain is going at 90 miles an hour down the information superhighway trying to work through a program or problem. Techhies also need to know when to work and when to buckle down and produce. All the creativity in the world doesn't cut mustard if the schedule is six months behind.

As we work and learn from each other, we realize that librarians are excellent sources of cartoons because they *READ* so many darn things. Clip those cartoons, librarians, techhies need them. If anything, the exchange of humor and cartoons is yet another viable method of communicating in the stressful, eventful, and empowering world of library service, to which both parties are committed.

Enjoy each other! The result is rewarding!

Send comments to: suzyq@pittstate.edu

Susan M. Johns-Smith
Axe Library
Pittsburg State University
1605 South Joplin Street
Pittsburg, KS 66762
Phone: 620-235-4115

This page last updated Thursday, 07-Nov-2002 10:35:03 CST