Describe Your Ideal Work Environment

I served on two search committees recently and blogged about the experience. I was struck by how tough it was to frame good interview questions. A lot of the questions we asked ended up being duds, not receiving a single response which illuminated anything about our candidates. Yet once you've asked a question, you're rather obligated to ask it of each person, for fairness' sake.

On the other hand, I also recently interviewed for a position and I was asked an excellent question: "Describe your ideal work environment." Why is this so great? I think it helps both parties, the search committee and the interviewee. The interviewee's answers almost of necessity must be revealing. So much so that the committee might rule them out based upon this question alone, which really aids the interviewee: if your own ideals are so at odds with an institution's, it's better to be ruled out ahead of time than to find that out a few months after you've started.

But what I really want to talk about is how I answered this question. Maybe it wasn't what the committee wanted to hear—I didn't get the position—but it felt good to articulate.

Control Over My Work Environment

Specifically, my computer. I want to run the operating system and software of my choice. Unfortunately, this is all-too-rare at most libraries and educational institutions.

@tararobertson it continues to shock the hell out of me how having admin privs to one's own work machine is somehow unusual or a bonus.
— John Fink (@adr) July 16, 2012

To be fair, I understood that there was no way I'd receive admin privileges at this position. But it's definitely a preference of mine. It's positively unproductive to limit the software available to information professionals. I do lots of development work, I have probably installed forty-plus packages on my Windows (not my first choice) machine at work. It's a waste of IT Support's time to come to my office to type in a password once a week; it's a waste of my time putting off a task because I can't install a requisite tool. I'm incredibly appreciative that MPOW allows me admin privileges.

Every institution should have a simple "admin quiz" one can take to receive appropriate privileges. I understand why we deny everyone by default; running an institution's computers is hard work and ensuring consistent security and software settings is a great aid. But those of us who are capable of administering our own computers, who know to run antivirus software (or just not run Windows...sorry, I'm belaboring the point) and avoid sketchy links in emails, should be given that prerogative.

While I've rambled quite a bit about computers, I also like to control my office environment. Now that I have my office set up the way I like, I'm rather attached to it. I like to have a standing desk, some room for pictures on the wall, some open space. I can do without, but I'd prefer not to.

Data-Driven Decision-making

I like to make decisions based upon data rather than my own feelings or opinions. That data doesn't have to be quantitative; I have a great appreciation for user experience research and I wish I had more time to devote to it. There's no substitute to seeing actual users perform actual tasks, whether it be searching for a peer-reviewed article or trying to find the print card vending machine.

This isn't a personal preference either, it's an institutional one. I love seeing data brought up in meetings, at presentations, in board meetings. It says something about an institution and its commitment to objectivity and success. Again, it's not all that common and that's understandable; collecting and analyzing data is difficult, time-consuming work. But recognizing the importance of those activities isn't.

Failure is Natural

As I've covered before, I have a great appreciation for failure. We cannot be successful in all our ventures and we often learn as much from the crash-and-burn projects as the epic wins. An institution that acknowledges that failure is a natural part of its own evolution is one I want to work for. I want to see presentations that not only say "gee, we really screwed up here" but also "and here's how we'll avoid the same mistakes next time." There's nothing more frustrating than seeing people cover up obvious mistakes because you just know that they'll be repeated in the future.

That's My List

or at least part of it, the main items certainly. What's yours? Is there anything in particular that libraries do well or struggle with?

Again, I think this question is more of a healthy exercise in articulating your own priorities rather than a wish list. I fully expect that I'll never work for an institution that gets flying colors in all three of these categories, but that doesn't mean that I shouldn't recognize my own predilections.

Teach While You're Learning Yourself

There's a (pretty reasonable) theory that the best way to learn is from the experts. They know what they're talking about, right? It makes sense, and those who have studied and worked in an area for years have valuable insights to share. They know the pitfalls, the broken assumptions, the brilliant hypotheses and they can communicate them.

But the experts have their disadvantages. The fundamentals are so ingrained in them, so second nature, that they speak a different language. A technical term on their lips has an intricate history, labyrinthes of connotations. The neophyte, on the other hand, has but glimpsed the adumbrations. They've learned a term only to find out their understanding was slightly askew. Their confusion is laden with value, with the very undulation of learning. It should be harnessed while it's prime.

Enough Abstraction Already

I'm engaged in a community of librarians who are steadily leveling up their technical skills. A lot of this happens in the Library Codeyear Interest Group (come to the Python Preconference at ALA!), but also on the ACRL Tech Connect blog where our posts are less prophets handing down commandments than regular ol' librarians sharing their inchoate knowledge.

A specific of example is the Codeyear IG's GitHub Project, which I started (though feedback from participants and Andromeda Yelton has been invaluable). I started the project despite being mediocre at Git and GitHub. I am not a software developer. Sure, I have a deceptive number of projects on my GitHub account, but I'm thoroughly amateur and still make embarrassing mistakes.[1] But that hasn't hindered the project's efficacy: we've had ten people complete the Getting Started tutorial and many more read the Tech Connect blog posts on it. If nothing else, it's upping the community's exposure to and understanding of awesome tools like GitHub.

Part of the success of the GitHub Project, I hope, is my ability to write for beginners. Having just started using version control myself, I'm hesitant to employ Git terminology which is familiar to people coming from other VC systems but not to people new to the whole class of software. For instance, rather than write something like git commit does just what it says: it stores the current contents of the index in a new commit along with a log message from the user describing the changes it's obvious that the commit command finalizes our changes and adds them to the project's history is a better explanation. But even with my valuable inexperience, I still assume familiarities that don't necessarily exist. An early participant noted that the keyboard shortcut to exit the git log command was never mentioned (it's the letter q, by the way). This is precisely the sort of key detail that is lost on experienced users. I'm no command line expert, but I know that q exits the less pager. It was a real hangup for me when I was learning, but now that I press it several times a day, it's cognitively absorbed. I forgot that it was something I had to learn, once upon a time.

Old News

Pedagogy has known that experts do not make great teachers for awhile. We've all heard of the move away from the "sage on stage" to the "guide on the side," which is related to the critique of top-down knowledge transmission. Other current movements, like "flipping the classroom" where lectures occur outside of class while time in the classroom is used for group projects, also come to mind. But we often fail to carry these lessons over to professional development; when you schedule conference sessions, do you look for Delphic panels like Top Tech Trends or amateur confessionals like Drupal Fail? More importantly, do you stop yourself from writing to a listserv, tweeting, blogging, or proposing conference sessions because you feel too inexperienced, too fraudulent?

A lot of librarianship is learning, whether it's how to teach information literacy or how to code, and we benefit as a community when everyone shares their own lessons. Go forth and edify, ye novices.

Footnotes

1.^ The history of my fork of a dotfiles repo has damning evidence. There's weird looking stuff if you run git log --pretty=online -n 50 --graph for what should be a fairly straightforward project.